Skip to content

add expiry_time to PendingOutboundPayment::StaticInvoiceReceived #3918

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

a-mpch
Copy link
Contributor

@a-mpch a-mpch commented Jul 8, 2025

Context

This is a follow up to Matt's comment from #3140

Whenever paying to an often-offline node and invoice has an expiration time of weeks / months / years and node does not come online soonish we would hold the HTLC for the entire time until "we remember that have to do something about it"

Solution

This sets a expiry_time to StaticInvoiceReceived using StaleExpiration that is defaulted (hardcoded) to one week. Then is used to time out any HTLC pending after that expiration time.

Some decisions over the way:

  • I thought that this flag is too scoped to async payments, so adding it to a router config would be more noise than actually useful.
  • Is not configurable. Like expiration time while waiting offers is not configurable, this one neither.

Not really sure about not being configurable but maybe is worth changing it in a follow up when being used.

@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Jul 8, 2025

👋 Thanks for assigning @valentinewallace as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

@a-mpch
Copy link
Contributor Author

a-mpch commented Jul 9, 2025

It is weird that mutants modify the constant to check for tests. Is it because we want to test based on the constant ? 🤔

fuzz failed because of a memory issue on the vm

@@ -2661,6 +2684,7 @@ impl_writeable_tlv_based_enum_upgradable!(PendingOutboundPayment,
(6, route_params, required),
(8, invoice_request, required),
(10, static_invoice, required),
(12, expiry_time, required),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This variant probably hasn't been written, but IMO we should still set the TLV type to an odd value to support downgrading from 0.2+ to 0.1. We can also set a default_value of 0, I think, so downgrading to 0.1 then upgrading would result in immediately timing out the payment, though it would be good to include a release note for that.

Suggestion:

Suggested change
(12, expiry_time, required),
(11, expiry_time, (default_value, StaleExpiration::AbsoluteTimeout(Duration::from_secs(0))),

+ a release note for the downgrade/upgrade behavior. Let me know if that doesn't make sense.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh would that mean that when upgrading from 0.1 to 0.2+ and default value is zero, everything from previous version would be timed out too?
Maybe being optional is better in this case and manage the None case as no expiry_time 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a commit using None I'm not loving it but kinda of works

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No one's using this feature yet almost certainly, so honestly I'd prefer to just time out payments when going from 0.1 to 0.2+ and having a release note noting that this will happen, so we can avoid the Option.

@ldk-reviews-bot
Copy link

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

@a-mpch a-mpch force-pushed the 2025-07-expiry-time-static-invoice-received branch from 9b282a4 to 58b51a5 Compare July 9, 2025 22:38
@a-mpch
Copy link
Contributor Author

a-mpch commented Jul 9, 2025

So I rebased it and added fixups for all comments beside the TLVs. That probable the default value being None is better.
My second thought on that issue is how can we tests these upgrade/downgrade mechanisms 🤔

@valentinewallace
Copy link
Contributor

My second thought on that issue is how can we tests these upgrade/downgrade mechanisms 🤔

IMO we're alright on upgrade/downgrade tests, I don't think anyone's using this feature

@a-mpch a-mpch force-pushed the 2025-07-expiry-time-static-invoice-received branch 2 times, most recently from 2a7c9a2 to e3bc8c3 Compare July 10, 2025 16:48
@a-mpch
Copy link
Contributor Author

a-mpch commented Jul 10, 2025

great, all comments should be addressed. I leave the fixup so changes are clear.

@a-mpch a-mpch requested a review from valentinewallace July 11, 2025 16:10
@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 2nd Reminder

Hey @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Copy link
Contributor

@valentinewallace valentinewallace left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay, feel free to squash!

Previous this commit if the StaticInvoice has an expiration time
of months or years would make our HTLC to hold for that time until
is abandoned.

This patch adds a defaults of 1 week of expiry time that the HTLC
will be held waiting for the often-offline node comes online.
@a-mpch a-mpch force-pushed the 2025-07-expiry-time-static-invoice-received branch from 9b548bc to 11ceee8 Compare July 18, 2025 05:06
@a-mpch a-mpch requested a review from valentinewallace July 18, 2025 05:07
@a-mpch
Copy link
Contributor Author

a-mpch commented Jul 18, 2025

thanks! rebased with all changes

Copy link

codecov bot commented Jul 18, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.00%. Comparing base (eae2bb1) to head (11ceee8).
Report is 32 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3918      +/-   ##
==========================================
- Coverage   89.02%   89.00%   -0.02%     
==========================================
  Files         166      166              
  Lines      121374   121377       +3     
  Branches   121374   121377       +3     
==========================================
- Hits       108049   108034      -15     
- Misses      10927    10935       +8     
- Partials     2398     2408      +10     
Flag Coverage Δ
fuzz 22.57% <0.00%> (-0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link
Contributor

@valentinewallace valentinewallace left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, landing with 1 review

@valentinewallace valentinewallace merged commit 2f9898c into lightningdevkit:main Jul 18, 2025
27 of 28 checks passed
@valentinewallace valentinewallace mentioned this pull request Jul 1, 2025
42 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants